💡 Motivation and Context

Third PR in the stacked Capture V1 series (stacked on #702). Adds the HTTP transport and partial-retry send loop for POST /i/v1/analytics/events, on top of the pure transforms from #702. Still inert — send_v1_batch has no caller until the consumer-wiring PR.

New in posthog/capture_v1.py:

• post_v1(...) — a single attempt. Bearer auth (no api_key in the body), the required v1 headers (PostHog-Sdk-Info, PostHog-Attempt, PostHog-Request-Id, PostHog-Request-Timestamp), and optional gzip. Returns the raw response; this is also the monkeypatch seam the test harness adapter will drive.
• parse_v1_response(...) — classifies one response without raising: 2xx parses the per-uuid results map (an unparseable 2xx body is flagged malformed), non-2xx best-effort extracts an error message, and Retry-After (delta-seconds or HTTP-date) is parsed in both cases.
• send_v1_batch(...) — the v1 sibling of Consumer._send. Loops up to max_retries + 1 attempts, but shrinks the batch to only the events the server tagged retry after each 2xx. ok/warning/absent events succeed silently; drop events are logged (a request the server accepted-but-dropped is not a delivery failure, so it is not raised). Raises CaptureV1Error (an APIError subclass, so the consumer's existing on_error(exc, batch) keeps working) on a batch-level terminal/transport failure or once retries are exhausted.
• CaptureV1Error / V1ParsedResponse / V1EventResult types.

Behavior choices, verified against the Rust contract and posthog-go's capture_v1_send.go:

• 429 is terminal in v1 (v0 retries it) — the backend signals overload via retryable 5xx + Retry-After.
• A stable PostHog-Request-Id and created_at span all attempts; PostHog-Attempt increments — so the backend can correlate/dedupe a retried batch.
• A 2xx with an unparseable body is terminal — re-sending against a broken success would loop forever.
• Backoff reuses the v0 policy (Retry-After wins, else capped exponential) so both wire protocols back off identically.

Also factors a shared gzip_compress helper out of request.post — pure refactor, no v0 behavior change (covered by the existing test_request.py).

💚 How did you test it?

posthog/test/test_capture_v1.py now has 74 cases (47 transform + 27 transport). New transport coverage: post_v1 header/url/no-key-in-body/gzip-magic; parse_v1_response success/malformed/missing-results/error-body-variants/text-fallback/Retry-After; and send_v1_batch driven by a stubbed post_v1 with mocked sleeps — all-ok, absent-uuid-accepted, partial-retry-shrinks-to-retry-uuids, stable-request-id + incrementing-attempt, drop-logged-not-raised, retry-exhausted-raises, malformed-2xx-terminal, 400/429-terminal-not-retried, 503-then-success (honors Retry-After), 503-exhausted-raises, transport-error-then-success, transport-error-exhausted-reraises.

ruff format/check clean; mypy clean on capture_v1.py + request.py; test_request.py (61) still green after the gzip refactor; regenerated references/public_api_snapshot.txt.

📝 Checklist

• I reviewed the submitted code.
• I added tests to verify the changes.
• I updated the docs if needed.
• No breaking change (additive; send_v1_batch has no caller yet).

🤖 Agent context

Autonomy: Human-driven (agent-assisted)

Authored with Cursor (Claude Opus 4.8) per the agreed plan. posthog-go's sendV1 is woven into its client lifecycle (channels, notifyFailure/notifySuccess, maxAttempts); this port instead fits posthog-python's Consumer._send shape — a synchronous loop that raises on failure so the existing upload() -> on_error(exc, batch) path fires unchanged — while preserving go's partial-retry algorithm, status matrix, stable-request-id semantics, and per-event drop/retry handling.